UNIX MAGAZINE 2002年10月号

キーフレーズ

UNIX MAGAZINE ファイルシステム iptables インターフェイス アドレス バケット IPv6 http:// Windows Linux フィルタリング 2002 Suffix Array fsck 場合 ネットワーク text www 設定 INTERFACE ファイル システム txt FORWARD () ルール スナップショット 機能 LAN ifra 対応 name オプション Web サーバー 利用 ルータ 文字列 masquerade ポート addr RTA フィルタ EXTERNAL struct DMZ 実行 クライアント 000 指定 コマンド sary プレフィックス return プログラム アプリケーション lntel プロセス array state TCP sin チェーン ifa co.jp CPU int 必要 作成 char アクセス FreeBSD ノード prefix インターネット 検索 style 可能 表示 NULL 処理 できる HDD プロトコル 使用 include グループ ICMP 接続 mksary JSP ESTABLISHED file ACCEPT MHz 情報 IPv4 INTERNAL

目次

咄 -1 譱を、い面い システムのサイズとは無関係に、サスペンド時間は 1 秒以 下に抑えられている。ソフト・アップデートを使用する場 合、ファイルシステムの破損は、 i ノードとデータブロッ クの損失に限られる。スナップショットと従来の fsck を すこし改良したものを組み合わせることで、ファイルシス テムを継続的に運用しながら、失われた i ノードやデータ プロックを取り戻すことができる。バックグラウンド fsck の所要時間は従来の fsck とはは伺しだが、通常は低い優 先側立で実行し、システム上のほかのプロセスの遅延をで きるだけ少なくすることカましい。 運用中のファイルシステム上て領域を回復するという問 題に対して、スナップショットは単純なガべージコレク ション・ユーティリティよりも面倒な解決策にみえるかも しれない。しかし、スナッフショットのコスト ( 約 1 , 300 行のコード ) は、運用中のファイルシステムを確実にダン プしたり、ファイルシステムを 1 日に数回バックアッフ するなどの便利な機能によって回収できる。 ・舸変は、バックグラウンド fsck の夫地検証を重ね、そ の信頼を石忍したうえで、システムの遅延を最小限に抑 えながら、ジョブを妥当な時間内に完了するための最適な 優先順位を模索するつもりだ。 ゲ 9 と現在の状況 スナップショットとバックグラウンド fsck は、 2001 年 4 月から FreeBSD 5.0 上で実現されている。スナッ プショット、ゲート機能、 fsck を使用するためのシステ ムコールの追加、および fsck 自イをの変更を含め、関連 するすべてのコードは、 BerkeIey スタイルの著イ料雀のも とにオープンソースとして提供されている。 参考意見を寄せてくれたことと、草稿を推敲してくれたことに 関し、 Rob KoIstad に感謝する。彼は説明にいくつかあいまいな 点があることを孑商してくれた。また、 Matthew Dillon 、 lan Dowse 、 peter Wemm をはしめ、カーネルに関する私の知識不 足に耐えながらバグの j 毆亦を手伝ってくれた FreeBSD の開発者 に感調する。 [ 参考文献 ] [ 1 ] G. Ganger, M. McKusick, C. Soules and Y. Patt, "Soft Updates:A Solution to the Metadata Update Problem ⅲ FiIesystems, ” ACM 石、 0 れ sac 0 れ s 0 れ UNIX MAGAZINE 2002.10 Corn 社、 Systems, 2 , pp. 127 ー 153 , May 2000 [ 2 ] D. Hitz, J. Lau and M. MaIcoIm, "FiIe System Design for an NFS File Server AppIiance, ” Proceedings 可 the Sa れ FT 、佖れ c な co USENIX Co れ / ℃れ ce , pp. 235 ー 246 January 1994 [ 3 ] J. Howard, M. Kazar, S. Menees, D. Nichols, M. Satyanarayanan, R. Sidebotham and M. West, "Scale and Performance ⅲ a Distributed System, ' ACM TT 、佖れ s 佖 c 0 れ s 0 れ Compute7 、 Systems, 6 , 1 , pp. 51-81 [ 5 ] M. McKusick, K. Bostic, M. Karels and J. Quarter- 〃 leme れ t 佖 0 れ , pp. 239 ー 250 , February 1999 Symposium 0 れ 0 era れ 9 Systems Design vs. Physical FiIe System Backup, ” T 厖 ris, D. Hitz, S. Kleiman and S. OMalley, [ 4 ] N. Hutchinson, S. Manley, M. Federwisch, February 1988 佖れ d lm- USENIX 'Logical G. Har- Co れ / et ℃れ ce , San Francisco, California, USA February 11 ー Originally published in Proceedings 可 the BSDCon 2002 「 Running "Fsck ”ⅱ 1 the Background 」 務めている。 ACM と IEEE のメンバーでもある。 の博士号を取得した。 USENIX の前会長を経て、現在は役員を でコンピュータ科学と経営管理工学の修士号、コンピュータ科学 ステムへの造詣カ架い。コーネル大学で電気 : 匸学の学位を、 UCB リリースを孑軍した。とくに、イ反想メモリシステムとファイルシ ピュータ利研究者として、 4.2BSD および 4.4BSD の開発と し、 CSRG (Computer Systems Research Group) のコン ア大ヾークレイ校 (UCB) に在籍中、 4.2BSD の FFS を実装 UNIX や BSD 関連の学 : 科て教鞭をとっている。カリフォルニ 籍や記事の執筆活動コンサルティングをおこなうかたわら、 ■ Marshall Kirk McKusick CO れ / er ℃れ ce , pp. 71 ー 84 , June 2000 Systems, ” Proceedings 可 the S 佖れ D を 0 USENIX dates: Asynchronous Meta-data Protection ⅱ 1 File Soules and C. Stein, "Journaling versus S0ft UP- ApriI 1994 佖 ge ド s イのれ田 4 pp. 3: 1-21 , O'Reilley & Associates, FiIe System Check Program ” , イ .4 BSD System イ 0 ル [ 7 ] M. McKusick and T. KowaIski "FSCK ー The UNIX USENIX Technical Co れ / et ℃れ ce , pp. 1 ー 17 , June 1999 ⅲ the Fast Filesystem,' FT 、 ee れ朝 Track the れれ社記 Technique for Eliminating MOSt Synchronous Writes [ 6 ] M. McKusick and G. Ganger, “ So 仕 Updates: A 〇 pera れ System, pp. 269-271 Addison Wesley, 1996 man, The Design 0 れ d / m eme れね 0 れ可 the イ . %BSD @MarshaII Kirk McKusick 14 2002 167

- を ' k はを、い 0 新い 表 6 アイドル中のファイルシステムてのパックグラウンド fsck の所要時間 ファイルシステムのサイズ糸幽繝 CPU サスペンド日繝 0.5GB 7.7GB 8.1 秒 0.025 秒 2.5 秒 61.5 秒 14.9 秒 0.050 秒 表 7 運用中のファイルシステムでのパックグラウンド fsck の所要時間 ファイルシステムのサイズ糸も幽繝 CPU 日繝サスペンド 0.5GB 7.7GB 122 秒 2.9 秒 591 秒 16.2 秒 0.025 秒 0.050 秒 もな遅延は、ファイルシステムのスナップショットを作 成、削除するために必要な時間である。スナップショット の操作にかかる時間については 4 節で説明した。 fsck の I/O はまとめて実行されるため、ディスクの ほはすべての帯域を使用することができる。バックグラウ ンド fsck は、 ( ファイルシステムを含む複数のディスク を同時に検査する従来の fsck とは対照的に ) 1 度に 1 っ のファイルシステム・ . パーティションのみを本査するが、 1 つの fsck だけでも、検査がおこなわれるファイルシス テム上 ( または同しディスクー E) のファイルにアクセスし ようとしているプロセスに深刻な遅延をもたらす可能性が ある。 領域の回復を急ぐ必要はないので、バックグラウンド fsck は、通常はほかのプロセスよりも低い優頂位で実行 される。ーヨ殳に、プロセスの優先頂位を下げるには、プロ セスの nice 値に正の値を設定する。これにより、 CPU に対するプロセスの優先頂位は低くなる。 fsck の性能はほ は完全に I/O に依存するため、 CPU に対する優先順位 を下げても実行時間への景彡響はほとんどなく、したがって I/O を発行する割合にも景グはない。 バックグラウンド fsck のように、 I/O の負荷か高いフ ロセスの資源使用率を下げる一ヨ勺な解決策として、ディ スクのストラテジー・ルーチンに小さな変更が加えられて いる。 I / O の要求が発行されると、ディスクのストラテ ジー・ルーチンは、ますプロセスが正の nice 値で実行さ れているかどうかを石忍する。ⅲ ce 値が正であり、ディ スクに対する未処理の I/O 要求がはかにも存在する場合、 プロセスは 100 分の nice 秒間スリーフ。状態におかれる。 したがって、十 4 のⅲ ce 値で実行されているプロセスは、 ディスクへの I/O 要求を発行するたびに 40 ミリ秒間ス リープする。このようなプロセスは、最大でも 1 秒間に 25 の I/O 要求しか発行できない。これは最新技術を用い 166 たディスクの帯域幅の約 3 分の 1 である。 nice 値が最 大 ( 十 2 ので実行されているプロセスは、 1 秒間に 5 つの I / O 要求に制限される。これは、ディスクへのアクセスで 競合するほかのプロセスがほとんど気つ、かないはど低い値 である。遅延が発生するのは、はかにディスクに対する未 処理の要求か存在する場合だけなので、アイドル中のシス テムでは、 I/O 負荷か高いプロセスでも最大速度で実行で きる。 アイドル中のファイルシステムで従来の fsck を実行す る際の所要時間を表 5 に示す。この fsck は nice 値 0 で実 行されている。この fsck はシステム上で唯一のアクティ プなプロセスなので、これは従来のディスク検査を実行す るのに最低限必喫な時間を示している。 アイドル中のファイルシステムでバックグラウンド fsck を実行するための所要時間を表 6 に示す。この fsck は nice 値 0 で実行されている。この fsck はシステム上で ーアクテイプなプロセスなので、これはバックグラウンド fsck を実行するのに最低限必要な時間にあたる。表 5 に示 した従来の fsck の夫行時間にスナップショットの作成お よひ削除の時間俵 1 および表 3 を参照 ) が追加されるた め、実行時間は予想された時間よりもすこし増えている。 4 つのプロセスか伺時に書込みをおこなっているファイ ルシステム上で、バックグラウンド fsck を実行するため の所要時間を表 7 に示す。この fsck は十 4 の nice 値で実 行されている。ほかの実行プロセスが優先されるため、実 行時間か約 10 倍に増えていることに注意してほしい。対 ほかのプロセスへの景グは、スルーブットの合引・ 照的に、 が 10 % 以下と最小限に抑えられている。 8> まとめと今後の課題 本稿では、 FFS のスナップショットを作成するガ去に ついて解説した。スナップショットを作成するファイル UNIX MAGAZINE 2002.10

表 5 アイドル中のファイルシステムでの従来の fsck の所要時 ファイルシステムのサイズ第幽 0.5GB 7.7GB 5.8 秒 50.9 秒 CPU 日繝 1.1 秒 8.3 秒 ソフト・アップデートを使用していること、フォアグラ ウンドでの検査が必要であるというマークが付いていない こと、バックグラウンドでの検査をおこなう際に書込み可 能な状態でマウントされていることか条件となる。これら の条件か満たされていれは、 fsck-ffs は終了コード 0 で 終了する。その他の場合は、 0 以外の終了コードで終了す る。ファイルシステムがクリーンである場合は 0 以外の 終了コードて終了するため、フォアグラウンドでの検査の 際に、ファイルシステムの状態がクリーンかどうかを検査 し報告することができる。 fsck 玉 s を一 F フラグ付きて呼 び出すと、検査はおこなわれないことに注意してはしい。 fsck-ffs は、フォアグラウンドとバックグラウンドのどち らの検査が必要かを判断し、適切な終了コードで終了する だけである。 fsck-ffs を -B フラグ付きで呼び出すと、指定された ( 運用中の可能生がある ) ファイルシステムで検査がおこ なわれる。修正は ( 前節で詳述した ) 訓整モードで重川乍し ているときに利用できるものに限られる。想定されていな いエラーか検出された場合、ファイルシステムにはフォア グラウンドでの検査が必要というマークが付けられ、 fsck- 飛はそオ ) 」 : の検査をおこなわすに終了する。 長年にわたる卩各や改良の結果、 fsck は I/O を最小限 に抑え、まとめて実行するように最適化されている。また、 fsck のデータ構造は、 CPU 日をほとんど消費しないよ うになっている。結果として、 fsck の実行時間は必要な I/O を実行するための時間で占められている。バックグ ラウンド fsck の陸能は、従来の fsck とはとんど変わらな い。同じアルゴリズムを使用しているため、 I/O の数やパ ターンは従来のプログラムとまったく同しである。更腰 求には、ディスクへの直接的な書込みではなくカーネル呼 出しが使用されるが、カーネル呼出しによるディスクへの 書込みは、通常は同じか、 ( ソフト・アップデートを利用 する場合は ) 若干少ない。バックグラウンド fsck でのお 7 バックグラウンド fsck の性能 UNIX MAGAZINE 2002 ユ 0 SC 翡 好評発売中 ! インターネットの 起源 ・ Katie Hafner 、 Matthew Lyon 著 ・加地永都子、道田豪訳 ・ A5 判、 336 ページ ・ ISBN 4-7561-3479-3 ・本体 2 , 500 円 + 税 誤った " 常識”を覆し、創設に携わった人びとの肉声を あますところなく伝える貴重な証言集 目次から 即断即決で 100 万ドル / 大聖堂を建てたのは誰か / 第 3 の 大学 / プログラムと格闘する日々 / トウルート宛必着 / ハッ キングと喧噪と / 電子メール / 手にしたロケット 参考文献、索引 Java プログラミング・ノート 国際化と 日本語処理 Where W 貶「 ds 5 ね y up Late The 0 ⅱ g ⅲ 5 0 「 The lnternet CAFE BABE ・風間一洋著 ・ A5 判、 312 ページ ・ ISBN 4-7561-3481-5 ・本体 3 , 000 円十税 Java による日本語処理、さらには国際化プログラミング に必須の知識を数多くのサンプル・プログラムを示し ながら平易に解説する。真の意味での "Write Once, Run Anywhere" を目指すプログラマーに最適の 1 冊 目次から Java はどんな言語か / 国際化と地域化 / Unicode / ロケー ル / 工ンコーディング / タイムゾーン / リソースパンドル / フォ ーマット出力と解析 / 文字列の比較 / テキストの境界解析 / インブットメソッド / 文字の表示 付録 : Unicode プロック / ロケール一覧 / 工ンコーティング名 一覧 / タイムゾーン D 一覧 / ユーロ通貨記号への対応 株式会社アスキー 〒 1 5 1 ー 8024 東京都渋谷区代々木 4 ー 33 ー 1 0 出版営業部 電話 ( 08 ) 535 ト 8194 165